A good description of the background art to the invention is provided in the applicants co-pending U.S. Pat. No. 4,644,493, filed Sept. 14, 1984.
In addition to the prior art identified in the referenced application, Uchenick U.S. Pat. No. 4,458,315 suggests a security procedure for protecting software in which the software is distributed with a key number (first key information). In order for the software to be run on a computer, the computer must have access to a device storing "second key information". The program will not properly execute unless the first and second key information bears some specified relation. The patent however does not describe use of a transaction token which forms an important component of the present invention, nor is there any apparent impediment to deter a pirate from merely altering the software so it can execute without this comparison step nor does the patent describe how the computer obtains access to the "record key information" in such a way that that access cannot be duplicated or forged.
Jones Futurex, Inc. describe a software protection product which employs a decryption board which stores a decryption key in "write only" mode. This product comes in fixed key and variable key models. The fixed key model would require the software vendor to personalize each different software copy to a different key. While the variable key product might not have this failing, the product description does not describe how the variable key can be loaded except to say this is accomplished by "an remote communications processor". Such a scheme for distributing decryption keys is inconsistent with the distribution methods in common use. This drawback does not characterize the system taught by this disclosure.
Best, in U.S. Pat. Nos. 4,168,396; 4,278,837 and 4,465,901, describes a program protection mechanism which makes use of enciphered programs. However, Best suggests that each copy of a program be customized so that it is only executable on a single microprocessor, i.e. in a single, physically unique microprocessor. This protection appears breakable by discovering the key needed to decrypt the software and by other cryptanalytic techniques. However, as a practical technique for protecting software, it is unusable. A software vendor must sell each copy of his software (which has been customized), along with the microprocessor which has been customized to run the associated software. The only alternative is for the vendor to identify which microprocessor the user owns so that the software can be customized for it. To the extent that the software vendor allows the software to be run on a class of microprocessors (say all 80286), then the protection is lost, for duplicates of the software will freely run on all microprocessors of the class.
The referenced U.S. Pat. No. 4,644,493 describes a method for recording data on magnetic media in such a way that the act of reading the data alters it. Such "read once" magnetic recordings cannot be created by conventional disk drives so they cannot be copied by conventional personal computers systems. As described in the referenced application a computer is associated with a physically and logically secure coprocessor and software as distributed on the magnetic media includes at least a significant section or portion which is encrypted. The magnetic media also includes an encrypted decryption key which must be used by the coprocessor to decrypt the encrypted portion of the software. The act of transferring the encrypted decryption key from the magnetic media to the secure coprocessor is linked to the mechanism which alters the data. This assures that, in the absence of extraordinary measures, the encrypted decryption key is not transferable once the magnetic medium has been read. This prevents the creation of copies of the distribution medium which can be employed on other computers, subverting the copy protection mechanism. Once the coprocessor has access to the encrypted decryption key, it can decrypt this key. In the course of executing the software the encrypted portion is decrypted by the coprocessor. This ensures that the software is executable, but prevents the user from obtaining access to the complete software package in decrypted form.
The mechanism described in the referenced application is extremely resistant to attack because the decryption key and the protected fraction of the software are never exposed to the user in unencrypted form. The owner of the software is allowed unlimited backup copies, but these backup copies are useless on any other personal computer (one which does not have access to the specific coprocessor already storing the decryption key). The protection system is open to any software writer for use and any hardware producer for manufacture because it requires no sharing of confidential information (key information) between the involved parties and its methods may be disclosed publicly without compromising its security.
However the read once magnetic recording has two vulnerabilities in a copy protection system. First it is always possible (although costly) to examine the magnetic medium and produce a device which will forge its behavior to a computer system. Second, a determined pirate may be able to build an apparatus which will restore the pre-read state of the "read once" recorded data that has been used to authorize the acceptance of a decryption key by a system. The re-initialized medium could then be used to illicitly "authorize" a second system.
The method, as described in the referenced application requires use of a public key crypto system. This architectural restriction limits the flexibility of the system. In addition the system described in the referenced application requires the use of a bus slot which may not be available on some systems or may be too valuable to a user. This is necessary to allow the coprocessor to observe the host processor bus operations so that it may assure itself that the appearance of the read once magnetic recording is not being simulated by a program on the host computer.
The present invention overcomes the above noted disadvantages in that it firstly does not require a dedicated bus slot for a physically secure coprocessor, it does not rely on public key crypto systems nor does it rely on read once magnetic media. In these respects it is both more versatile and more resistant to attempted piracy than the earlier system.
The present invention is based on the recognition that today's software distribution techniques distribute to the user, in addition to the software itself, the right to execute that software. That is, more particularly, when software is sold to the typical user, the user acquires not only the software itself but the right to use it. However, he can, with a typical personal computer, duplicate the software and distribute it along with the (implied) right to use it to others. The invention seeks to separate the software, from the right to use it. Further, it seeks to place the means of creating these Rights-to-Execute in the hands of the software authors or their representatives. It also seeks to do these things with no perturbation to the existing or planned channels of software distribution and minimum change to the means by which software is prepared for distribution. As will be described below, in accordance with the present invention, the typical software purchaser may still duplicate at will the software he has received from the vendor. However, he cannot duplicate the right to use the software; in fact he receives a single right to use the software. To become effective, that right to use must be installed in a suitable coprocessor, and it is only when the right to use is installed on the suitable coprocessor (which is associated with the host computer on which the user intends to run the software) that the software becomes executable. Other copies of the software that the user might make are not executable on any other host computer (even if such other host computer is associated with another suitable coprocessor).
In accordance with the present invention software can be distributed on magnetic media (such as tape or floppy disk) or by other means (telephone lines, cable or broadcast transmission). The software is partitioned into an encrypted portion P.sub.e and an unencrypted (clear text) portion P.sub.c. The choice of the partitioning is made by the software vendor with the understanding that only the encrypted portion will be protected from piracy. The encrypted portion, P.sub.e of the software will be decrypted and executed by a physically and logically secure coprocessor if the coprocessor possesses the decryption key which embodies the right to execute. The protected part of the software is, thus, never exposed in plaintext form and never executed by unauthorized systems. The coprocessor may be attached to the user's personal computer either on the system bus or through a I/O or other communication port.
In order to be effective, and decrypt the encrypted portion of the protected software, the coprocessor must be provided with the decryption key (Right-Right-to-Execute or RTE, also referred to as AK or Application Key) needed to render the encrypted portion of software executable. The key (RTE or AK) must be transferred to the software owner's coprocessor in such a way that the transfer mechanism cannot be reused or reproduced by a user and thus grant key transfer to other personal computers. This is accomplished by associating the effective transfer of the decryption key into the non-volatile memory of the coprocessor with a transaction token, e.g. the presence of the transaction token is required to effectively transfer the decryption key to the coprocessor. The token is very resistant to forgery for reasons which are described below and its information content is destroyed during the transfer transaction. The token has information content which is known to the coprocessor because it is identified in an encrypted file. This file is called the Encrypted Token Description or ETD. This identification is authenticated to the coprocessor by the fact that it is encrypted with the same key (AK) which the software vendor has used to encrypt the protected portion of the software. The ETD may be distributed to the user by placing it in a dedicated register in the token, by recording it on the distribution medium, or by distributing it by other means.
The software vendor supplied key (AK) is made available to the coprocessor by supplying it, in encrypted form, with the program via the software distribution medium or other means as described in the case of the ETD. In the general case, the key used to encrypt the AK is selected from a list of Coprocessor Supervisor Keys (CSKs) which is stored in all coprocessors supplied by a given vendor.
The function of encrypting the software vendor's decryption key with one of these stored encryption keys is a service provided by the coprocessor so that the store of keys (CSKs) need never be exposed to the software vendor. The coprocessor which the software vendor uses to encrypt the software vendor's keys may be precisely the same type of coprocessor as the user employs to decrypt and run the software. Alternatively, special processors may be sold for this purpose or standard processors may be enabled to perform this function by an encrypted message from the hardware manufacturer. These options may be useful in giving flexibility to the marketer of such devices.
For the same reason the software vendor's decryption keys (such as AK) are never exposed to the software user, the hardware vendor's encryption keys (CSK) are never exposed to the software vendor. This system thus has the property that no information need be shared between hardware and software manufacturers in order to use the protection provided. In addition, a single encryption system such as DES may be used for all cryptographic functions.
In accordance with the invention, in order to access the transfer token, the coprocessor is provided with a data path which allows communication with a hardware sub-system such as a cartridge. This data path may utilize a connection to the cartridge supplied by either the host (such as a PC) or the coprocessor. The cartridge contains an electronic memory with properties that change (in a manner to be described) in response to whether the memory is being read from or written to. This cartridge sub-system must be extremely difficult to copy in the sense that a substitute is very unlikely to be created by a user which can fool a coprocessor into accepting it as verification of the user's right to store a given decryption key (AK) in the user's coprocessor. Since the connection to the sub-system is physically exposed, the transaction which uses this connection as its communications medium must be forgery-resistant.
To be forgery-resistant, each transaction must be effectively unique and verifiable by the coprocessor. The technique by which this security is obtained is described below.
The sub-system which is used to verify the right of a user to a particular decryption key is referred to as a transfer token. The necessary functions can be implemented using programs executed by a micro-processor or by using a dedicated hardware system. Inasmuch as the most economical implementation of a transfer token will be a dedicated hardware system, this is the version that is described.
The transfer token hardware and its information content must be kept physically secure to avoid its access by the user through means which bypass the forgery prevention feature. One implementation of this physical security is described in co-pending application Ser. No. 927,309, filed Nov. 5, 1986 the disclosure of which is incorporated by this reference. The same technique may be employed to render the coprocessor itself physically secure and to protect its memory contents from its exposure to a user. Since tokens can be implemented as a single, continuously powered, integrated circuit chip, no additional physical security is needed. If the physical security of a token were broken, then no cryptographic keys would be revealed and only the single associated software package could be redistributed.
Thus, in accordance with the invention, software to be protected is partitioned into a plain text portion and an encrypted portion; the encryption key (AK) used to encrypt the software is known only to the software vendor. The protected software provided to the user is associated with the software decryption key, in encrypted form (EAK). The software decryption key (AK) is encrypted with the hardware vendor's encryption key (CSK) which is not known to the software vendor. This encryption is a service performed by such coprocessors. The software and encrypted decryption key (EAK) may be associated with information describing a transfer token (TOKEN DATA) by encrypting that description under AK. The correspondence between the content of the token and the token data (after decryption under AK) indicates to the coprocessor that that particular AK may be stored for future use. The authorized user is provided with a token, which in a preferred embodiment is implemented in the form of a hardware cartridge. The transfer token is physically and logically secure, so that a sufficient fraction of its information contents is not available to the user. The transfer token, or the hardware cartridge incorporating the transfer token has a read once feature whereby the first time the hardware cartridge is read the contents are altered so that the authorization which the hardware cartridge represents cannot be effectively reused by the user. The user is also provided with a physically and logically secure coprocessor. The physically and logically secure coprocessor has in permanent memory the hardware vendor's decryption key(s) CSK1, CSK2, etc. The data descriptive of the token will typically be transferred with the software.
The first time the user attempts to employ the protected software, he couples the physically and logically secure coprocessor to the computer system in which the protected software is to be run and also couples the hardware cartridge containing the transfer token to the computer system.
On the first running of the software the encrypted software key EAK is transferred to the coprocessor and is decrypted by the coprocessor using the required CSK to obtain AK. For reasons which are explained below, this transfer is temporary, the coprocessor will reject the transfer if the conditions described below are not met. A verifiable portion of the contents of the hardware cartridge, i.e., the transfer token, is also transferred to the coprocessor using a forgery-resistant query/response protocol; this process alters or destroys the contents of the hardware cartridge. The information revealed to an observer of the query and the response is insufficient to allow a forger to construct a correct response to another coprocessor query. The transfer token can be "refilled" with information by a software author, but the refilled transfer token will only authorize a coprocessor to accept an AK from that author. The physically and logically secure coprocessor determines whether or not the transfer token is effective by determining whether or not it corresponds to an expected transfer token. Assuming the transfer token is found acceptable, the coprocessor then stores the software decryption key AK in its permanent memory. At this point the transfer is effective so that the coprocessor can use AK to decrypt and run protected software.
Once the software decryption key AK is stored in the permanent memory of the coprocessor, the protected software can be executed. The plaintext portion of the protected software is executed by the user computer system. The encrypted portion (the protected portion) of the software is decrypted upon loading by the coprocessor. The logical and physical security of the coprocessor memory prevents the user from having access to plaintext or executable form of the protected software.
On each subsequent use of the protected software the software decryption key AK now stored in the permanent memory of the coprocessor is used to decrypt the encrypted portions thereof. The user can make as many "backup" copies of the software as he desires; however without access to a logically and physically secure coprocessor storing the decryption key AK, any "backup" copies of the software are unusable since the encrypted portion of the software cannot be decrypted.
Accordingly, the invention provides a method of restricting use of software to an authorized computer comprising the steps of:
distributing said software in a form in which at least a significant portion is encrypted,
providing a coprocessor in association with a potentially authorized processor, which coprocessor has a memory space secured against external access for storing decrypted software and operating instructions,
coupling said software to said processor, coupling a distinct right-to-execute to said coprocessor and storing said distinct right-to-execute in said secure memory of said coprocessor,
in the presence of said distinct right-to-execute, decrypting and storing said significant portion of said software in said coprocessor for the period needed to execute such software as needed by the user, and
executing said stored software portion in said coprocessor.
Typically, in conjunction with execution of the decrypted software by said coprocessor, the authorized processor will execute the remaining portions of the software, e.g. the originally unencrypted portions.
The distinct right-to-execute in a preferred embodiment comprises a decryption key for the encrypted portions of the software. While the decryption key may be distributed along with the software, it is distributed in encrypted form. The coprocessor is provided, during manufacture, with the key (CSK) required to decrypt the software decryption key. Without further protection, however, this would authorize any coprocessor to run any software distributed in accordance with the preceding description; this would not meet the purposes of software authors. Therefore, the coprocessor requires further evidence of the user's right-to-execute; that evidence takes the form of an authentic (unused) hardware cartridge. If and only if the hardware cartridge meets the challenge of the coprocessor will the software decryption key be rendered effective. The coprocessor has available to it (by one of several alternative routes) what is referred to as token data. This token data can be coupled to the coprocessor in encrypted form so that the path by which the encrypted token data is made available to the coprocessor need not be secure. The token data is encrypted using the same software decryption key. The cartridge stores, in clear text form, the token data, and hence the hardware cartridge must be physically and logically secure. The coprocessor challenge to the hardware cartridge is in the form of a query, the hardware cartridge responds to the query by returning a reply which is a function of both the query and the token data. This function does not reveal enough about the token data to allow the behavior of an unused token to be reproduced. An example of such a function would be the selection of 50% of the token content on the basis of the query content. As the hardware cartridge generates the response, all the clear text token data which it had stored is overwritten or destroyed. As a result of the query/response process, the coprocessor receives the selected portion or transformation of the clear text token data. The process is arranged so that even though the communication path between the coprocessor and the hardware cartridge is not secure, someone monitoring the transaction (for example copying the query and the response) would still have insufficient information to simulate the behavior of the cartridge. While the coprocessor only receives the selected portion or a tranformation of the clear text token data, since the coprocessor also has available to it both the query and the entire clear text token data (having decrypted the encrypted token data), the coprocessor has available to it all the information it needs to determine whether or not the response identifies an authentic cartridge.
The communication path between coprocessor and hardware cartridge can either be direct (by coupling the hardware cartridge to a port in the coprocessor) or be indirect via the host or processor to be authorized.
A preferred example of a suitable query is a random number, of specified bit length. The query is input to the hardware cartridge and is used to select among distinctive and exclusive portions of the clear text token data as stored in the hardware cartridge. In a simple example the query can be binary so that if the clear text token data is divided into two portions, each bit of the query can be used to select a bit from the first or the second portion. A selected bit makes up one bit of the response, and simultaneously the selected and unselected bits are overwritten or otherwise erased. In this example then, the bit length of the query is equal to half the bit length of the clear text token data. Because the communication path between the coprocessor and the hardware cartridge is unsecured, it is assumed that a pirate will be able to copy the query and response. But the pirate is incapable of controlling the query another coprocessor will generate and therefore the response which he is aware of is insufficient to allow him to simulate the effect of an authentic hardware cartridge.
The software, the associated encrypted decryption key EAK and information respecting authorized transfer token(s) may be provided on a magnetic medium (floppy disk or tape). Alternatively, that information can be provided via a communication link (telephone line, CATV, etc.). The coprocessor which is employed in accordance with the method need not be permanently attached to or hardwired into the user computer system. However, in order to execute the protected software on the computer system, the computer system must be capable of communicating with the coprocessor. If the coprocessor does not yet store the software decryption key (AK), the coprocessor must also be associated with a transfer token so that the decryption key AK can be accepted by the coprocessor. The hardware cartridge containing the transfer token is arranged so that it is capable of authorizing an appropriate transfer of a decryption key AK on one and only one occasion. This assures that the user can transfer the software decryption key AK to a single coprocessor. Although the user may freely backup the software medium, the protected program can only be executed in cooperation with a coprocessor containing the software decryption key. Because the coprocessor is physically and logically secure, the stored software decryption key cannot be copied. Because the hardware cartridge containing the transfer token is both physically and logically secure it cannot be copied, and since the act of transferring the software encryption key causes the token information content to be altered or destroyed, this process can only be executed once.
As described above, the software distribution medium included information describing the token. This information is encrypted to protect it from exposure to unauthorized sources. However, as will be described below, it is not at all essential for the encrypted token description to be contained within or associated with the software distribution medium. It is an advantage if tokens are all unique. For a unique token description to be contained on each software distribution medium requires in effect that each software distribution medium be unique. It would be more advantageous if all software distribution media could be identical as this minimizes manufacturing costs. This can be achieved by providing the hardware cartridge with the means for storing the encrypted token data. All unique information can thus be isolated to the hardware cartridge.
As will be described below the transactions to be effected are varied in dependence on whether or not the encrypted token data is associated with the software distribution medium or the hardware cartridge containing the clear text token data.
In either case, the token will be tested by the coprocessor in such a way that the testing process (even though carried out via unsecured conductors) does not reveal sufficient token data to successfully forge the authorization which the token represents. To implement this process a "random" number is generated by the coprocessor (and retained by it for future use). The "random" number is used to interrogate the token which returns to the coprocessor that portion of the token data which is selected by the "random" number. At the cartridge, both the token data which is selected (and transferred to the coprocessor) as well as token data which is not selected is destroyed. In this fashion, even if the response of the hardware cartridge is recorded by unauthorized individuals, it is useless except in the limited situation where the coprocessor generates the identical "random" number or the forger guesses the required reply.
For a forger to fool another coprocessor by presenting that coprocessor with a forged reply to its random number query, either the second query must be identical to the first, or the forger must guess the correct response to the new query. Both of these can be made less likely by using longer queries. By combining good random number generation with sufficiently long queries to and replies from the token, the job of forgery can be made arbitrarily hard.
The coprocessor accepts the encrypted software key EAK from either the token cartridge or the software distribution media (preferred) and decrypts it using a coprocessor supervisor key CSK stored in the coprocessor at the time of manufacture.
The coprocessor then accepts the encrypted token data (from either the token cartridge or the software distribution medium) and, using the decrypted software key AK, decrypts the token data.
The coprocessor can then combine the "random" number and the clear text token data to determine the "correct" response of the hardware cartridge to its "random" number query. The "correct" response calculated by the coprocessor can then be compared with the actual response of the hardware cartridge, if they compare favorably, the right of the user to have use of the key AK has been established. This use does not include the ability to determine the actual content of AK.
In the event that the encrypted token data is not associated with the software distribution medium, it can instead be stored in a dedicated register in the hardware cartridge. The clear text token data is stored in a specialized register set which on reading will only provide a portion of the stored information where the provided information is selected by the response of the read components of the token on the basis of the selecting random number. These components may further transform the selected information using the part of the stored information which was not selected. Before or after the coprocessor has queried the hardware cartridge and received its response (the combination of "random number" and clear text token data), it can continue interrogating the hardware cartridge so as to read out the encrypted token data. Of course, this means that the encrypted form of the token data will be available to the user (and any unauthorized individual). But this no more undermines the security than having the encrypted token data on the software distribution medium where it too is available to the user and unauthorized individuals. It should be noted that the token contains no cryptographic keys. If the coprocessor is considered to be a trusted receiver of secret information (AKs) then the token can be likened to a wax seal on an envelope which assures the receiver that no other receiver has accepted that message (an AK). The token, thus gives the software vendor control over the total number of coprocessors that are able to execute their software. It is this control which is absent at present and allows software piracy to exist.
It should be clear that this system's solution to the piracy problem is based on amending both the personal computer and the floppy disk by the addition of a hardware component which compensates for the exposures that allow piracy. In the case of the personal computer, that exposure is the availability of the complete address and register space of the computing system to user scrutiny and command. In the case of the floppy disk (or any other distribution or storage media) it is the fact that a functional reproduction of the media can be made. It is possible to describe the amendments in a manner which makes the applicability of this system to computing systems other than personal computers clearer.
The openness of the existing computing system is addressed by the addition of a coprocessing system. This system is needed to implement two levels of privilege above that of the user of the system. This is necessary even in the case that the computing system has a CPU which implements privilege. In such a system, some user is still responsible for loading the operating system and could provide an operating system which supports his access to protected portions of the vendor's code. Even if the operating system were burned in ROM in the CPU, the user would not be denied physical access to the protected code.
The privilege structure dictated by this problem is thus a branch on whatever structure is already present. This branch contains two levels which are effectively parallel and separate from the existing structure. The two levels of privilege which are added to the computer by the coprocessor (or are designed appropriately into the computing system) have distinct functions. The lowest of the two levels provides a space in which a portion of the vendor's code can be executed as a service for the part of the vendor's code executing in the open memory of the host computer. The higher level of privilege in the branch is used to perform the secure transactions which prevent proliferation of the rights-to-execute when they are installed or used. These transactions are available as a service to the lower level of privilege or the host.
This architectural extension of present computing systems provides support for data processing security functions in general by providing means for the trustworthy execution of software. The changed privilege structure provides an execution space in which the software provider has a privilege greater than the system user. This privilege level is parallel to, but distinct from, the system operator. At this privilege level the software provider may execute his product as a service to the user without giving access to it as a software object. This software is then trustworthy in the sense that it cannot be changed or observed by the user, but only accessed as a service. The uses of such trustworthy execution will be obvious to those skilled in the system security area.
A second level of privilege is provided as part of this additional privilege structure. It is the responsibility of this level of privilege to control the operations needed to cause the software product to execute. This level of privilege is trustworthy in the sense it will only allow execution of code if it has been given the right to execute by the software provider. This level of privilege has the additional job of isolating applications executed at the lower level in the event that multiple programs are executed there. This is a classical operating system function and is necessary to keep code at the lower level trustworthy.
In accordance with this aspect, the invention provides a method of securing protected software against unauthorized use without perturbing existing channels of software distribution and, at the same time, not interfering in user's creation of unlimited backup copies of protected software, said method comprising the steps of:
(a) providing to a user a physically secure coprocessor and coupling said coprocessor to a user host computer to support bidirectional communication therebetween to create a composite computing system including said host computer and said coprocessor,
(b) providing logical security to said coprocessor by:
(1) providing a first privilege level including first level secure memory and first level operating instructions, secured against access or variation by said user, for executing protected software, PA1 (2) providing a second privilege level including second level secure memory and second level operating instructions, secured against access or variation by said user or any author of protected software, for controlling authorization for execution of said protected software by said first privilege level,
(c) distributing protected software in a form in which at least a portion is inexecutable by said host computer but which is executable by said coprocessor but only with authorization by said second privilege level,
(d) distributing a further tangible element distinct from said protected software representing a right to execute said protected software,
(e) providing said composite computing system access to said protected software and to said further tangible element,
(f) verifying authenticity of said further tangible element by said coprocessor at said second privilege level,
(g) altering said second level secure memory in a distinctive fashion to reflect a determination by said second privilege level of authenticity of said tangible element, and
(h) executing said protected software so long as said alteration of said second privilege level secure memory is detected and denying said request if said alteration is not present.
From the preceding it should be apparent that the first privilege level has the function of executing protected software as a service to the software vendor and to the user, but protecting that software from access by the user. The second privilege level includes the key management functions of acquiring a right to execute and, once acquired, copying the necessary decryption key into the secure memory space (second privilege level) of the coprocessor. As distributed, of course, the protected software is inexecutable by the host computer since at least a portion is encrypted; the software is executable by the coprocessor once it has authorization by the second privilege level. The further tangible element is the hardware cartridge storing the transfer token. The manner by which the coprocessor verifies the authenticity of the transfer token has already been described in detail. The alteration to the second level secure memory is the writing therein of the software decryption key. Whenever execution of the protected software is requested by the user, access is made, via the coprocessor's second privilege level to the secure memory space to determine if the appropriate software decryption key is present; if present, the coprocessor initiates decryption of the protected software and storage of that software in the coprocessor's first level secure memory space. Subsequently, the second privilege level authorizes execution by the first privilege level. Of course, if the necessary software decryption key is not present, the user's request to execute the software is denied.